When a mower (e.g. Ecovacs GOAT G1, A1600 RTK, A3000 LiDAR Pro) is
mowing, its firmware pushes spontaneous `onMapTrace` MQTT messages.
They flow through `messages.get_message()` which falls back via
`_LEGACY_USE_GET_COMMAND` to `GetMapTrace`, whose parser does not
support the on-wire format used by recent mower firmware
(observed: 1.15.13). The parse fails inside
`_handle_error_or_analyse` and emits a WARNING per push.

In one user setup this produced 217 520 `Could not parse getMapTrace`
warnings over 3 days (~70 k/day, ~50/min during mowing), bloating the
HA `homeassistant.log` and the recorder DB by ~100 MB.

Mowers do not expose a `map=` capability in their hardware
definitions, so successfully parsed map-trace data would have nowhere
to land anyway — the fallback is pure noise on these devices.

This adds an optional `device_type` argument to `get_message` and
`get_legacy_message`. When the device is a `MOWER`, map-related
legacy messages (`onMapTrace`, `onMapSet`, `onMapSubSet`,
`onMinorMap`, `onCachedMapInfo`, `onMultiMapState` and their
`get/off/report` variants) are skipped silently before reaching the
parser. Vacuums and devices with no specified type fall through
unchanged.

`Device._handle_message` reads `device_type` defensively via `getattr`
so existing test mocks that don't expose the dataclass field on
`spec_set=Capabilities` continue to work — they fall back to the
no-filter path.

Tests:

- `test_get_messages` (existing 7 cases) — pass unchanged.
- `test_get_messages_device_type_filter` (10 new cases) — verify
  mowers skip map-related legacy fallbacks while non-map messages
  and other device types remain unaffected.
- Full suite: 707/707 pass, no regression.

Refs: DeebotUniverse#1376 (Disable getMapTrace for Goat)
Refs: DeebotUniverse#852 (GOAT A1600 RTK Support)

Address review feedback on DeebotUniverse#1565:
- Drop the explanatory comment block above ``_MAP_LEGACY_COMMANDS``
- Replace the ``device_type == DeviceType.MOWER`` check with a
  capability-based one. ``get_message`` now takes ``has_map: bool``
  (keyword-only) and ``get_legacy_message`` skips map-related fallbacks
  when the device does not expose a ``map`` capability — independent of
  whether the device is a mower, vacuum, or future device class.
- ``Device._handle_message`` derives ``has_map`` from
  ``capabilities.map`` via ``getattr`` so test mocks unaffected.

Address review feedback from edenhaus:
- Pass the whole `static: StaticDeviceInfo` object to `get_message()`
  instead of extracting `data_type` and `has_map` separately at the
  call site.
- Remove `getattr` in device.py — access `capabilities.map` directly
  since the attribute is defined on the dataclass.
- Remove `lru_cache` on `get_message` since `StaticDeviceInfo` contains
  non-trivially-hashable `Capabilities` objects. The function is cheap
  enough without caching (string lookups + one regex).
- Update tests to use real `StaticDeviceInfo` fixtures (yna5xi with map,
  xmp9ds without map) instead of passing primitive params.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>